As may be appreciated, in a computer game or visual computer simulation or the like (hereinafter, ‘game’), visual graphics for the game are rendered on a continuous basis as a series of visual frames. In connection with any particular frame, then, an object may be created to be displayed in connection with the frame, an object may be populated with some sort of fill or the like, etc. Likewise, in connection with any particular frame, an object previously created and/or populated may be modified. As should be appreciated, a particular frame may have anywhere from one to ten thousand objects or more associated therewith, and in connection with such frame none, some, many, most, or all of such objects may be created, populated, and/or otherwise changed. Generally, any change to an object in a frame may be achieved by way of one or more computer-type calls with respect to such object. Thus, it is not inconceivable that thousands or tens of thousand of calls can be made in connection with any particular frame of a game.
As may be appreciated, many obstacles exist in developing the visual graphics for a game. Such obstacles include, among other things, performance in terms of speed in rendering each frame and the like, correctness of each rendered frame, and understanding how resources are best employed in an efficient manner. Moreover, such obstacles may be compounded if the game is to be instantiated on any of several types of hardware configurations and software configurations, where each such configuration can potentially present unique rendering issues.
In dealing with such obstacles, it is at times useful to be able to capture a particular rendered frame, and in particular capture such frame in a manner so that the frame can be re-rendered on each of several computing devices, each having a particular hardware configuration and software configuration. Moreover, it would be useful in doing so to be able to re-render the particular frame on a particular computing device without the aid of the application that initially rendered the frame. Thus, the computing device need not have the application installed thereon, and the rendering on the computing device is independent of the application.
Recognizing that any particular frame may rely on previous frames both to create and populate objects relevant to the particular frame, one possible method of capturing a rendered frame is to capture and store all calls made in connection with all previous frames and also all calls made by the particular frame. However, it is to be appreciated that the sheer volume of all of such calls may become enormous, especially if the particular frame is serially positioned well into the game, and such enormity may pose issues both in storage and transmitting of the calls for the frame.
Accordingly, a need exists for a method by which a particular rendered frame may be captured and re-rendered in an expeditious and efficient manner, and without the aid of the application that initially rendered the frame. Also, a need exists for such a method by which such capturing and re-rendering may be achieved without capturing all calls made in connection with all previous frames. In particular, a need exists for a method of identifying and storing only those calls made in connection with previous frames that are needed in connection with the particular frame, as well as the calls made in connection with the particular frame. Thus, the particular frame may be re-rendered by playing a run file containing such needed calls to re-construct the environment of the particular frame, and also containing the calls made in connection with the particular frame. As should be understood, such a run file may be played without the application on one or more computing devices to identify performance, correctness, and understanding issues as between different hardware configurations and software configurations.